Thanks for the fix and the clear diagnosis @Nisker, you read the spec exactly right.

• CTAP 2.1 §6.8.3 and §6.8.4 send the GetNext subcommands with only the subCommand parameter.
• The stateful commands section lets authenticators fail a continuation with CTAP2_ERR_NOT_ALLOWED unless it directly follows Begin or another GetNext.
• Our old loop broke this in two ways. It attached a pinUvAuthParam, and it sent a getInfo between Begin and GetNext.
• YubiKeys enforce the strict reading, the Token2 is lenient.
• libfido2, Chromium and python-fido2 all send GetNext bare.

Reproduced here on a YubiKey with two passkeys under one RP. On master:

DEBUG user_verification:ctap2_get_info: CTAP2 GetInfo successful
TRACE ctap2_credential_management: request=Ctap2CredentialManagementRequest {
  subcommand: Some(EnumerateCredentialsGetNextCredential), subcommand_params: None,
  protocol: Some(Two), uv_auth_param: Some([155, 189, 175, ..]) }
DEBUG ctap2_credential_management: Received CBOR response status=NotAllowed
Error: Ctap(NotAllowed)

With this PR, same device and credentials:

TRACE ctap2_credential_management: request=Ctap2CredentialManagementRequest {
  subcommand: Some(EnumerateCredentialsGetNextCredential), subcommand_params: None,
  protocol: None, uv_auth_param: None }
DEBUG ctap2_credential_management: Received CBOR response status=Ok
DEBUG ctap2_credential_management: CTAP2 CredentialManagement successful

I pushed two commits on top of your branch:

• Regression tests pinning the wire format. They fail on master.
• A fix for authenticators that only advertise credentialMgmtPreview. Begin resolves the 0x41 preview command from getInfo, but GetNext no longer went through that path, so it would have gone out as 0x0A. Begin now records the command set it resolved and GetNext reuses it.

Nice catch, thanks again!